【レポート】「ふくおかＦＧ ＤＸ推進基盤の構築」 ～おいしいデータレイクの作り方～ #AWSSummit

DA事業本部の春田です。

AWS Summit Online絶賛開催中！ということで、本記事では「CUS-54: 「ふくおかＦＧ ＤＸ推進基盤の構築」 ～おいしいデータレイクの作り方～」の内容についてまとめていきます。

セッション情報

• 株式会社ふくおかフィナンシャルグループ ビジネス開発部 主任調査役 常盤 和宏 氏

ふくおかフィナンシャルグループでは、DX を推進するべく、ビッグ・データ分析基盤として、データレイクおよび高度分析環境を構築しました。AIの時代が訪れ、産業構造が大きく変わる中、AIを活用するには、ビッグ・データの蓄積・整備・意味付けが必要です。ビッグ・データを正しく理解、分析し、使いこなす組織への変革が急務であり、ビッグ・データは経営資源となり得ると考えています。新たな価値をもたらすデータレイクを、AWSマネージドサービスのみを組み合わせることで構築いたしました。その道程をご説明します。

※セッション動画は以下リンク

おしながき

1. 準備編 これからデータレイクを作る方向け
2. 調達編 これからデータレイクを作る方向け
3. 調理編 データレイクを構築中の方向け
4. 実食編 データレイクを運用中の方向け
5. 食後の感想
6. 調理法 レシピの一例を公開

準備編 これからデータレイクを作る方向け

DXを推進するためには

• ふくおかフィナンシャルグループの中期経営計画に、DX推進を掲げている
• DXは「アイデア」✕「テクノロジー」✕「挑む力」
• DXは企業が生き残るための進化
  • あらゆる企業・組織が、持続可能な社会に向けて転換する
  • デジタル技術を利用して、現実にある社会問題を解決する
• 事業部門が主人公となりベンダと共創する
  • 従来はIT部門が先導してデジタル技術を活用していた
  • これからは事業部門が競争優位性を上げるために導入する
• PDCAではなくDCPAサイクルで推進する
  • アイデア生成から意思決定までを俊敏に実行できる体制
  • やってみて（Do）、検証して（Check）、正式に計画して（Plan）、具体的に進める（Action）
  • リーンスタートアップ
• note:
  • 日本ではエンジニアなどのITの専門家の75%がITベンダ企業に属し、ユーザ企業に属する割合はわずか25%
    • 世界はこの状況とは真逆であり、ITの専門家の70%以上がユーザ企業に属する
  • DXは企業の新しい価値を創出することなので、IT部門やベンダに丸投げしない

ビッグ・データの必要性

• これからの時代はビッグ・データ活用がビジネスを変えていく
• AIの時代が訪れ産業構造を大きく変えている
  • AIを活用するには、ビッグ・データの蓄積・整備・意味付けが必要
  • ビッグ・データを正しく理解、分析し、使いこなす組織への変革が急務
  • ビッグ・データは経営資源となり、新たな価値をもたらす
• 可視化、創造、予測
  • 情報を可視化する
    • ビッグ・データを分析することで顧客ニーズ、経営状況など様々な「情報が見えてくる」
  • 歴史を知り未来を創る
    • ビッグ・データを活用し、新たなビジネスモデル、業務効率化など自社に「変化をもたらす」
  • 中長期の予測を可能とする
    • 分析をもとに顧客に新たなサービスを提供したり、品質向上により「競争優位性を確保する」

• データレイク構築の目的
• DX推進のためのビッグ・データ分析基盤の整備
  • データレイク」+「高度分析環境」
  • ①社内のデータ群を、見極め、浄化し、「データレイク」に集約する
  • ②ビッグ・データを高速に分析できる「高度分析環境」を構築する
  • ③この環境を活用して「デジタル人財」を育成する
  • → 人が環境をつくり、環境が人をつくる
• 分析基盤を活用した顧客中心アプローチの実現
  • 新商品・サービスの創出
    • ビジネス仮説の試行的な検証
    • AIによるデータ活用
  • 既存事業の高度化・収益化
    • 事業部門間の協業・共創
    • 変容に俊敏に応じる柔軟性

調達編 これからデータレイクを作る方向け

• 分析基盤に求められるもの（デジタルトランスフォーメーションを推進するためのガイドライン（DX推進ガイドライン）（METI/経済産業省）より抜粋）
  • 体制・仕組み
    • 複雑化・ブラックボックス化しない
    • ユーザ企業自らがシステム連携基盤の企画・要件定義
  • 実行プロセス
    • ビジネス環境の変化に対応
    • 共通プラットフォーム
    • 技術負債の低減・または破棄
    • ビジネスモデルの変化に迅速に追従
  • 料金体系
    • サービスを使用した分だけ課金の体系にすべきか？

• 調達方針の決定
  • ベンダー4社の中から、一番指標に近いAWSを選択
  • データレイク用パッケージの導入ではなく、AWSマネージドサービスを組み合わせてデータレイクを構築
• AWSの徹底的なリサーチ
  • AWSサービス機能の調査と資料化・共有化
  • 試行環境の構築と検証・要件抽出を自社で実施 → ITベンダと共創
  • データレイク調達時の要員と作業ボリューム
    • 人数: 3人（AWS初心者）
    • 調査（資料化）: 2ヶ月（20機能）
    • 試行環境構築: 1ヶ月
    • 要件書作成: 1ヶ月（100ページ）
  • 今では、局所的にはITベンダーと同等か、それ以上の知識をもつチームに成長

• 試行に次ぐ試行
  • あれこれ試して知ることの重要性
  • 使う人のことを考える想像力の重要性
    • データサイエンティストやアプリケーションエンジニアにヒアリング
    • 現状の問題点やどのように使いたいかをリサーチ
  • メモを取ることの重要性
    • Wikiの活用

調理編 データレイクを構築中の方向け

• データレイク構成図
  • 堅牢なセキュリティ（Private Network）
  • 安全性と自由度のバランスに苦心
• オンプレ環境
  • 社内からデータレイクへデータを移出・移入する領域
  • AWSへはDirect Connectで専用線接続
  • グループ配下の3銀行（福岡銀行、熊本銀行、親和銀行）を含めた600テーブル以上
  • 過去データ10年分も合わせると、データ総量は数１０テラバイト
• Data Lake層
  • データを精錬しながらデータレイクとして完成させる領域
  • Edge、Cold、Warm、Hot層のS3バケットを通り、データを浄化する
  • S3にParquet形式で保存
  • 従来のDWHと比べ、安価に大規模なデータレイクを構築可能
  • ETL処理は差分方式 → 最も苦心した点
• Analysis層
  • データレイクを使用して、分析やシステム・アプリケーションを開発する領域
  • 用途に合った分析や開発が実現 → DX推進につながる
  • 他のAWSサービスもシームレスに連携可能
• API Hub層
  • データレイク内で開発したアプリケーションを外部へAPIとして公開する領域
  • API Gatewayを使用して外部連携

• Edge/Cold/Warm/Hot
• "データの沼"にしないために、データをどう綺麗にためるか？
  • Edge
    • 移入データの関所
    • お金を扱う銀行のデータは、厳格な型やバリデーションが大事
    • スキーマ（型/桁）を維持するために、RDSを介す
  • Cold
    • 移入データの保管所
    • Parquet形式にて保管、以降の処理を高速に行うための準備
    • RDS → S3のExtract/Loadが主体
  • Warm
    • データレイク本体の保管場所
    • Coldデータを精錬して格納する領域
      • 欠損データの補完や型の変換、テーブルの合成など
    • S3 → S3のTransformが主体
  • Hot
    • データウェアハウス(DWH)、データマート(DM)
    • Warmデータを加工して格納する領域
    • KPIやプロジェクトごとの加工済みデータが保存
    • 用途によってS3とRDSを使い分ける設計
      • 機械学習用データ → S3
      • 特徴量計算 → RDS
• Parquet(columnar storage format)の採用
  • 並列分散性能を向上するために、パーティショニング・バケッティングを最適化
  • データのスキャン量の削減

• ビッグデータの移出入（オンライン）
  • オンラインデータ（DB2）を、社内の中継サーバーからEdge層のRDSへ移出
  • Lambdaでデータの移出完了を検知し、Glue Workflowsをキック
  • Glue Workflowsにて、 Edge RDS → Cold S3 → Warm S3の一連のETL処理を実行

• ビッグデータの移出入（オフライン）
  • 過去のオフラインデータ・セット（Sas7bdat）を、SFTPにてEdge層のS3ヘ移出
  • Glue Job(Python)にて、Edge層のS3内のデータセットを順次Edge層のRDSヘ移入
  • RDSへの移入完了後、Glue Workflowsをキックし、一連のETL処理を実行
  • 1ヶ月あたりのデータ量によって、1つのテーブルの移入が完了するまでに数十日かかるものもある
    • → クラウドのため運用監視コストが低い分、気長に待っている

実食編 データレイクを運用中の方向け

• Amazon SageMaker
  • データサイエンティストのための個室研究環境
    • インスタンスタイプ変更、ライフサイクル変更による、個室ごとの増改築が可能
    • Pythonライブラリなどのインストールを自由化
    • CodeCommit（Git）との連携による研究者間のリソース共有
    • カスタマイズされた機械学習コンテナ（ECR）の整備と提供（銀行特有のアルゴリズム最適化）

• AWS Cloud9
  • プロジェクトルームとしてのCloud IDE統合開発環境
    • 社内、在宅、リモート勤務などを問わずチーム開発、ペアプログラミングを実現
    • Glue Job（python）、Lambda、Lambda Layerなどの開発も集約、Deploy自動化
    • オンライン、バッチ、API開発を支援

• AWS Lambda
  • 分析基盤の運用ツールとして活用
    • 時間指定によるインスタンスの一斉停止・起動（働き方改革・コスト削減）
    • 行内からのデータ移入監視によるGlue ETL処理のキック（TCO削減）
    • 利用者増加時の環境自動作成（TCO削減）
    • 移入状況サマリ処理などのBoto3を使用した簡単なバッチ処理の実行（TCO削減）
  • 分析基盤で開発した機能・サービスをAPI公開
    • API Hubなるデータレイクの出島を作成し、外部とのAPI連携を実現
    • データレイクのセキュリティ・堅牢性を維持しつつ、外部との連携を可能に
    • 機械学習モデルによる与信スコアリングAPIを自社のオルタナティブ融資サービスへ提供
    • サーバレスなので、運用負担ゼロ、費用も使った分だけ、MVP（Minimum Viable Product）に最適

• AWS Glue
  • 完全マネージド型のETLサービス（Spark Shell）
    • 速い: 数千万件、500カラムのトランザクションデータも十数分で処理
    • 安い: ジョブごとにDPU数を調整でき、使った分だけの時間課金
    • 美味い: Pythonコードなので痒いところに手が届く
  • ETL汎用スクリプトを開発しGlue Jobを大量生産
    • 日次、月次で大量の社内データ（数TB）の差分を移入する必要があった
    • 数百テーブル✕3銀行分のGlue Job/Workflowを手動で作成することは非現実的
    • Edge(RDS) → Cold(S3) → Warm(S3) → Hot(S3)のそれぞれの汎用スクリプトを作成
    • パラメータ+汎用スクリプトの組み合わせでGlue Jobを大量生産 → 短期間で安定した移入を実現
  • Glue Workflowsによる一連のETL処理の自動実行
    • トリガによる自動起動
    • カタログ最新化のためのCrawlerの実行
    • 開発用、本番用への日次データの同時デリバリー
  • 業務のバッチ処理開発に採用（Python Shell）
    • Lambdaの15分の壁をGlue Job（python）で解決
    • Cloud9で業務処理を開発・テストし、Pythonパッケージ化
    • 他のPython Libraryと合わせてGlue Job実行時にインストールするだけ

• Amazon Athena
  • サーバレスのクエリサービス、これぞデータレイクの意義
    • 社内では数日かかる集計処理が秒で完了
    • 機械学習のための前処理や、Ad-hocな特徴量生成が高速に実行でき、試行錯誤を支援
    • データレイク関連のサービスで、最も費用対効果が高くなっている
  • ParquetのPartitioningやBucketingが性能最適化の鍵
    • Where句などで使用される項目を設定することでスキャン数を削減できる（Index的な意義）
    • Partitioning: データを複数のパーティション（フォルダ）に分割保存すること、負荷の水平方向への分散
    • Bucketing: データをパーティション内に複数のファイルとして分割保存し、負荷分散
  • Athena APIを使用したPythonのラッパークラスを独自開発してSageMakerとの連携
    • クエリ結果のダウンロード
    • DataFrameヘの読み込み
    • CTAS（Create Table As Select）クエリの実行
    • CTASクエリのOverwrite 処理の実装

食後の感想

• 機能 〜そのものが持っている働き〜
  • ◎ セキュリティを維持しつつ、データレイクおよび分析基盤として充分な機能を提供できる
  • △ 全体的にコンソール機能が弱く、実運用するためには補完する運用ツール開発が必須
• 性能 〜そのものが持っている能力〜
  • ◎ 社内より高速な処理が可能になり、データドリブン、試行錯誤を支援できる
  • △ 現時点では、大規模運用に難がある（API粒度、AWSコンソールの表示速度）
• 仕様 〜ものを作る際に決めた設計〜
  • ◎ マネージドサービスを組み合わせることで、安価で迅速な開発が可能
  • △ サービス間でAPI仕様にゆらぎや差異があり、不統一感が否めない
• 品質 〜一連の固有の特性が要求事項を満足している度合い〜
  • ◎ サービス毎に充分な要求機能・性能を満たしており、日々改善も行われている
  • △ 個々のサービスが競争、アジャイル開発されおり、改善スピードに不均一感が否めない

→ 総じて、素質充分だが荒削り、プロ仕様でコンソールなどはなおざり

調理法 レシピの一例を公開

※セッション動画では取り上げられていないため、内容は資料のAppendixスライドをご参照ください。

公式スライド